Ingredients:

• some lame DNS server
• logcheck
• spamassassin

The last couple of days I've been plagued by some DNS errors that kept showing up in the logcheck mails for my home server which I was busy migrating from one box to another, doing an upgrade from etch/i386 to lenny/amd64 at the same time. So, plenty of stuff going on to confuse the issue. I kept getting the following messages every hour (anonymized):

named: connection refused resolving 'somedomain.org/NS/IN': xxx.yyy.zzz.nnn#53
named: connection refused resolving 'somedomain.org/NS/IN': xxx.yyy.zzz.mmm#53
named: connection refused resolving 'ns1.somedomain.org/AAAA/IN': xxx.yyy.zzz.mmm#53
named: connection refused resolving 'ns2.somedomain.org/AAAA/IN': xxx.yyy.zzz.mmm#53
named: connection refused resolving 'ns1.somedomain.org/AAAA/IN': xxx.yyy.zzz.nnn#53
named: connection refused resolving 'ns2.somedomain.org/AAAA/IN': xxx.yyy.zzz.nnn#53

The times were fairly regular: once just before the hour, most 2 minutes after. I fetch mail at around that time, but also at other times, so possible but unlikely. The 2 minutes after was the first real clue: some cron job maybe? After disabling logcheck the messages no longer appeared in the log. Enable it again, and they were back. Additional confusion was caused by the fact that the domain had "debian" in its name, but it was somewhere obscure. So why was logcheck causing a lookup for that domain? This did confuse me enough to waste some time looking for some silly weird (default) configuration problem in some package. Enter spamassassin. Apparently that was parsing the message body, recognized "somedomain.org" as a host name, and proceded to do a DNS lookup as validity check. So we have the following loop, started off by something causing an initial DNS lookup for the domain, which fails and gets logged:

• logcheck reports the failure during its next check
• spamassassin processes the logcheck mail, spots the domain name and does a new set of lookups, which fail and get logged
• logcheck reports the failures during its next check
• ...

Duh. I remember struggling with probably the same problem a couple of years ago, but then it was a lot more severe: masses of repeating DNS errors for obscure domains. At that time I failed to get to the bottom of it and ended up just ignoring the errors by adding the following option in my bind9 configuration:

logging  
    category lame-servers   null;  ;
 ;

Anyway, now I just no longer pass logcheck mails through spamassassin. (Although filtering out these DNS errors in bind9 can be perfectly valid.)

Ingredients:

• some lame DNS server
• logcheck
• spamassassin

The last couple of days I've been plagued by some DNS errors that kept showing up in the logcheck mails for my home server which I was busy migrating from one box to another, doing an upgrade from etch/i386 to lenny/amd64 at the same time. So, plenty of stuff going on to confuse the issue. I kept getting the following messages every hour (anonymized):

named: connection refused resolving 'somedomain.org/NS/IN': xxx.yyy.zzz.nnn#53
named: connection refused resolving 'somedomain.org/NS/IN': xxx.yyy.zzz.mmm#53
named: connection refused resolving 'ns1.somedomain.org/AAAA/IN': xxx.yyy.zzz.mmm#53
named: connection refused resolving 'ns2.somedomain.org/AAAA/IN': xxx.yyy.zzz.mmm#53
named: connection refused resolving 'ns1.somedomain.org/AAAA/IN': xxx.yyy.zzz.nnn#53
named: connection refused resolving 'ns2.somedomain.org/AAAA/IN': xxx.yyy.zzz.nnn#53

The times were fairly regular: once just before the hour, most 2 minutes after. I fetch mail at around that time, but also at other times, so possible but unlikely. The 2 minutes after was the first real clue: some cron job maybe? After disabling logcheck the messages no longer appeared in the log. Enable it again, and they were back. Additional confusion was caused by the fact that the domain had "debian" in its name, but it was somewhere obscure. So why was logcheck causing a lookup for that domain? This did confuse me enough to waste some time looking for some silly weird (default) configuration problem in some package. Enter spamassassin. Apparently that was parsing the message body, recognized "somedomain.org" as a host name, and proceded to do a DNS lookup as validity check. So we have the following loop, started off by something causing an initial DNS lookup for the domain, which fails and gets logged:

• logcheck reports the failure during its next check
• spamassassin processes the logcheck mail, spots the domain name and does a new set of lookups, which fail and get logged
• logcheck reports the failures during its next check
• ...

Duh. I remember struggling with probably the same problem a couple of years ago, but then it was a lot more severe: masses of repeating DNS errors for obscure domains. At that time I failed to get to the bottom of it and ended up just ignoring the errors by adding the following option in my bind9 configuration:

logging  
    category lame-servers   null;  ;
 ;

Anyway, now I just no longer pass logcheck mails through spamassassin. (Although filtering out these DNS errors in bind9 can be perfectly valid.)

Well, no, neither FOSDEM nor Debian are dead. But FOSDEM '09 is gone, over, and dealt with. It was a breeze, for the most part. I'm still not very happy with the booth; that needs to be done better next year. Help and suggestions in that area are more than welcome. One thing that more than deserves a follow-up is Lucas' post about FOSDEM:

On a more sad note, the worst talk of the week-end was without any possible doubt Frans Pop's release team bashing. Nobody is claiming that the release management of the lenny release cycle was perfect: there's always room for improvement. But given the context and the constraints, I think that they did a very good job. Frans' talk boiled down to: "The release team doesn't know what they are doing, I would have done much better because I'm so qualified."

As the person responsible for allowing Frans on the schedule in the first place, while being fully aware of the relationship between Frans and the release team (not at first, but certainly in time to kick him off if I'd have wanted to), I'd like to comment on that. First of all, I do not agree that the last statement in the above is true. Frans showed a few stories of things that went on in the release team, and gave his opinion on what he believed went wrong. He also explicitly said, at the beginning of the talk, that none of the talk was meant personally; that he wanted to offer some constructive criticism instead. I believe he did not fail in doing that, but of course YMMV. Secondly, and more importantly, I do not believe it is healthy for Debian (or any project, for that matter) to reject criticism. Indeed, nobody is claiming perfection. I do not believe any venue where talks can be had should be a good news show. People in a position of power not just the release team, but also, say, the DPL, ftp-masters, buildd maintainers and whatnot have received our trust to do what they need to do to the best of their abilities. If someone in the project would believe that I can significantly improve my work as buildd maintainer, it is not just their right, but indeed their duty to inform me of that fact. This is exactly what Frans was attempting to do, and there is nothing wrong with that. It is also not as if he's not tried reasoning with the release team first. He has made suggestions, which have gotten ignored. I feel that talking to more people about what he feels is right, to see whether they agree with him, is the next logical step to take, and that this it is exactly what Frans was attempting to do at FOSDEM. Having said that, I agree that finishing the talk late was a very bad thing. If anything, a talk on a subject like this should have more, not less, time for discussion. So while I do not agree that his intentions were wrong, I do agree that the execution could have been better. There, that was criticism too. Now, what's next? Oh yes, suggestions. If people have suggestions on how to improve the Debian presence at FOSDEM next year (especially, as above, ideas for creative use of the booth would be welcome), then please send me an email, making sure the subject contains the word 'FOSDEM', so my mailfilters know what to do with it. You'll preferably do so now, while FOSDEM is still somewhat fresh in your memory; I'll take notes and use those for doing better next year. Thanks,

Of course, I was in Brussels this week-end, for FOSDEM. I gave a talk about Ultimate Debian Database (slides here) in the Debian devroom. The conclusion was UDD is ready, go play with it! so you know what you should do now! FOSDEM in general was great and huge (see the video from Quim Gil if you still doubt that) as usual. On a more sad note, the worst talk of the week-end was without any possible doubt Frans Pop s release team bashing. Nobody is claiming that the release management of the lenny release cycle was perfect: there s always room for improvement. But given the context and the constraints, I think that they did a very good job. Frans talk boiled down to: The release team doesn t know what they are doing, I would have done much better because I m so qualified. Giving such talks at FOSDEM, in front of an audience with many people not involved in Debian development, is really insulting. To make things worse, he finished the talk late, not leaving any time for questions/discussion, so the audience might be left with the impression that his opinions are representative of the opinions of DDs.

In August I got a very nice HP 2510p notebook which is now my main system for development. This took a while for two reasons. First of all the system did not resume 100% reliably. This has now been solved, although the final patches needed for that will only be in 2.6.29, but that's no problem as I run upstream kernels anyway (I do quite a bit of kernel testing). Kudos have to go to Rafael J. Wysocki who has been doing a huge amount of work to improve the suspend/resume code in the kernel. Second of all I wanted a docking station so I could continue to use my 19" monitor, with the laptop's LCD as second display. I bought the docking station in December. The challenge then was to automatically (de)activate the external display when the notebook is (un)docked. Unfortunately there are no ACPI events, but the hp-wmi module (written by Mattew Garrett) sends docking events to the input subsystem. I wrote a small program to catch these events and a script that uses xrandr to switch displays. There were two issues with that setup. The first docking event was getting lost, but I managed to fix that. And the X server would crash when starting some applications (einstein and virtualbox) after undocking, but there's a patch for that too now. The notebook is now really well supported and stable.

• suspend/resume works completely reliably
• the docking station works nicely and so does the dual display setup
• wireless works nicely
• the SD card reader works (was used to develop support for MMC/SD cards in Debian Installer)
• the accelerometer works (so I can play Tux Racer and Neverball by tilting the notebook) using the lis3lv02d module, and Pavel Machek recently even added freefall detection, including example code to park the hard disk (targeted for 2.6.30)
• the fingerprint reader works, though I'm not sure I actually want to use that for logging on to the system

The system is currently running Debian/lenny with a KDE desktop and a 2.6.29-rc3 kernel. Working with upstream developers to get this far has really been worthwhile, and fun.

FOSDEM is a 2-day weekend of insanity. 218 talks this year; if you want to understand exactly how insane that is, have a look at the schedule grid. There are 19 rooms where events are held; possibly more, since I understand not every devroom has sent in its schedule yet. Might be hard for people to make a choice that way, I guess. Now there're supposed to be abstracts of each talk on the FOSDEM website, but reading them all can be quite tedius. In an effort to help, at least for the Debian devroom, here's the schedule for our devroom with a bit of explanation of what it's about. Note that this is mainly aimed at people not familiar with Debian; those who are should probably understand it enough by looking at the titles. Saturday: 13:00 - 14:00: 'Outside broadcast on a budget - the DebConf video team and DVswitch'. DVswitch is the software used to create those excellent Debian videos. The best ones yet, IMO, are the ones of Debconf8. Check them out. There's nothing Debian-specific about DVswitch, except that it was written by Debian people. It's a great way to do live Internet .ogg streaming by using nothing more than DV cams, Firewire, and plain old Ethernet. 14:00 - 15:00: 'Ultimate Debian Database: datamining Debian made easy!'. UDD is a SQL database containing a shitload of data related to Debian, and which should allow easy datamining. Hence the title. This probably won't be of any interest to people who are not either a Debian Developer or a statistician, but I might be mistaken. 15:00 - 16:00: 'Introducing DDE, Debian Data Export'. This is a new project Enrico came up with, and which is related to the same subject as the previous talk. I don't know much more beyond what's in the abstract. However, given the fact that Enrico is going to be doing this talk, it can't be bad. Seriously. 16:00 - 17:00: 'The Debian status quo on the Openmoko Neo Freerunner'. Yup, Debian runs on the OpenMoko, and has done so since Debconf8, last august. This talk should give some more insight; if you have an OpenMoko, this definately is for you. 17:00 - 17:30: 'Running Debian on Inexpensive Network Storage Devices'. I've been running Debian on a Thecus N2100 for a few years now, and it's great. There are more options, however, and Martin does most of the hard work related to these devices. He's done a similar talk on the two previous FOSDEMs (go check out the videos), and this one will mainly be an update on what's going to be new in Lenny. 17:30 - 18:15: 'Grid Computing with Debian, Globus and ARC'. These guys are a group of academics from three different universities who've been doing grid computing (i.e., something like 'SETI@Home', but then somewhat different) with Debian and some other technologies. They'll be explaining how, exactly. I don't know much about this talk; it could be great, or it could fail miserably. I guess we'll see. 18:15 - 19:00: 'What does the DPL do?'. This is really firmly targetted at Debian people. If you're not in the least interested in how Debian does things, you'll be bored. Sunday 09:15 - 10:00: 'The state of Virtualization in Debian'. If you're a Debian user interested in virtualization, this talk is for you. Henning will explain what virtualization options exist in the upcoming 'Lenny' release, and how to use them. 10:00 - 11:00: 'TDebs'. This might not be too interesting to you unless you happen to be involved in Debian infrastructure. TDebs don't exist yet, but will sometime soon; Neil will be explaining how, why, and what. 11:00 - 12:00: 'Internationalization in Debian: How to improve further?' If you're interested in i18n, this is probably for you. 12:00 - 13:00: 'The Common Debian Build System (CDBS)'. CDBS is one way to build a Debian package. This is probably only of interest to Debian people. 13:00 - 14:00: 'Release management in Debian - can we do better?'. Frans isn't a member of the release team, but has some criticism on how they function. He intends to present his arguments in order to start a discussion. This is Debian internal kitchery, really. 14:00 - 15:00: 'Lenny - the road to release'. Neil is a member of the release team, and is going to explain how we got to the current state. I hope he'll also explain why we still haven't released. I guess we'll see :-) 15:00 - 16:00: 'The long road to KDE4 in Debian'. Um, yeah. I'm not a KDE guy, but I understand some other people are. In any case, might be an interesting talk even if you don't use Debian, since I understand it will look at some of the new features in KDE (and how they relate to packaging). 16:00 - 17:00: 'Debian and Google Summer of Code 2008: wrap-up and insights'. I guess Leslie will be there. The speaker was a student working on Debian during this year's SoC, and he will present what's been accomplished. There, that's it. Now my only hope is that there'll be many people attending. If previous editions are any indication, however, that won't be a problem.

There have been 470 mails during the last month in the DFSG violations threads on -vote@, but only 10 posters have contributed more than 10 mails so far:

85 Robert Millan
51 Manoj Srivastava
18 Pierre Habouzit
18 Josselin Mouette
16 Thomas Bushnell BSG
14 Stephen Gran
13 Frans Pop
13 Ean Schuessler
13 Adeodato Simo
12 Russ Allbery

Is someone working on a summary of the discussions? I would really hate it if we were asked to vote on this, with a “for details, see the -vote@ archives” footnote. (Robert Millan sounds like a perfect candidate for this task :-) )

After my last post about the ongoing debate on the new process to accept and handle debian project members, Rapha l Hertzog proposed an alternative organisation which could be a solution, but misses the most important fact: how the people in charge of the process would be chosed and dismissed. Rapha l Hertzog wants that we consider a group of skilled and trustfull people in charge of giving and revoking powers to lower class of developers, on a per-event basis. Their procedure would be an internal vote amongst this group, and they would be called the "Debian Community Managers". Although it could be a good idea, it really misses the MOST IMPORTANT FACT: how they are chosed and to whom are they responsible. As a reply to my comment, Rapha l propose that they would be elected at first, and then nominated/revoked on the basis of the decision procedure mentioned above. Not only is it exactly what have been in place for the last years in the various core teams, but also it is a dangerous naive vision of how powers and regulations must happen. Before the Debian project started to consider these issues, the various ideas to build a system where the majority is ruled by a minority and the means to prevent the most important issues has already been studied, in the field of Law and how to write a Constitution for a democratic system. The goal of a democratic system is to put some higher power in the hand of several, but prevent as much as possible any issue. And preventing means act before shit happens, not after. Furthermore, power has to be divided into several domains, where the people in charge of these domains are strongly seperated and share as less common interest as possible. Hence, the goal of a constitution is to weaken power and put barreers, even if this leads to slow and frustrating reform processes. In the same idea, elections, which redraw the positions, are planed on a regular basis, and if the previously elected people were good, they are relected, not the opposite, in which if they aren't good they are dismissed. Again, we prevent issues, so the requirement to be responsible for what you did is implicit. And, last, it is well known that the less direct a decision process is, the less democratic it is. Hence, one should always prefer direct elections to indirect nominations. Now, coming back to Debian, we can have a very similar distinction in the various powers available:

• Legislative power: GR
• Executive power: core teams and DPL
• Justice power: no formal role.

Now, the propositions, and all the various discussions are motivated by either the fact that there are issues with some developper's behaviour, which falls into the justice side and for which we already have a wide history of long debates before we act whatever the act is, or the executive power to give rights and introduce a new member in the project. Yes, we clearly miss a role in the project for applying rules and sanctions and deciding about these issues. However, we really ought to fix it the right way. In particular, never should we, in any way, give any justice power to someone in charge of any of the other power, in particular core teams. And the same for the right to appoint new members. For instance, to name an issue, the Frans vs. Sven issue would have been really different if there wasn't any kind of personal interest and power in the people in charge of the decisions. In real social systems, the right to apply a sanction or give new rights is a very dangerous power. It suppose a high level of separation between your personal interest, and the decision you have to make, as well as a high level of responsability against the people who trust you. We used to claim that Debian was not a democracy, but a meritocracy where technical skills are the ultimate ranking for deciding who's good or bad when giving reponsabilities. I have never been convinced by this approach, which I consider, just as anarchy, as valid for a small group of developers, but completely naive for a big group. Now, it is clear that the issues that we are dealing with in this situation have nothing to do with technical skills. In particular, the original proposition creates a class of non technical contributors, documentation writers, or translators etc... Furthermore, if you look back in the past, there have been a lot of situation where the issue, and its solution had nothing to do at all with technical issues, like issue mentioned above, or the Duck Tank or whatever it was called. We really should drop this naive idea that technicals skills are the only way to put on decision on the project. That is no longer how it works, nor a solution to the human issues that we face now.

When the Debian installer starts, it will normally ask you what language you want to install in and gives you a really long list of languages to choose from. Unfortunately, that's not how it works when you install on a headless NAS device. The reason for this is that installations on NAS devices are done via SSH and the installer normally brings the network up after asking the user for their language. So we'd simply skip the language question and go with English. When Timo Jyrinki recently mentioned that he couldn't install in Finnish, Frans Pop pointed out that localechooser has changed a lot since etch and that it should now be possible to have the language question after setting up the network. This turned out to be correct and I managed to choose a different language but the installer still showed everything in English. Frans reminded me that the installer drops all translations that are not necessary but unfortunately this happens too early in our case. He pointed me to a variable that determines whether translations will be dropped. So in lenny translations will not be dropped on NAS devices that have enough RAM and users will be asked when they connect to the installer via SSH what language they'd like to install in.

After a short discussion time, my proposals have been ACK'ed and we will have 63 languages supported, including English, in Debian Installer for Lenny. Etch had 58 supported languages. The final winners are (alphabetical order of ISO code): Amharic, Arabic, Belarusian, Bulgarian, Bengali, Bosnian, Catalan, Czech, Welsh, Danish, German, Dzongkha, Greek, English, Esperanto, Spanish, Basque, Finnish, French, Irish, Galician, Gujarati, Hebrew, Hindi, Croatian, Hungarian, Indonesian, Italian, Japanese, Georgian, Khmer, Korean, Kurdish, Lithuanian, Latvian, Macedonian, Malayalam, Marathi, Norwegian Bokm l, Nepali, Dutch, Norwegian Nynorsk, Punjabi, Polish, Portuguese, Brazilian Portuguese, Romanian, Russian, Northern Sami, Slovak, Slovenian, Albabian, Serbian, Swedish, Tamil, Thai, Tagalog, Turkish, Ukrainian, Vietnamese, Wolof, Simplified Chinese, Traditional Chinese Newcomers for Lenny are: Amharic, Welsh (back), Irish, Marathi, Northern Sami, Serbian We lost Estonian which was in Etch. Those that missed the deadline are of course all other languages of the world. We will put focus on languages where an effort started at some moment but could not be complete enough: Afrikaans, Estonian, Persian, Armenian, Icelandic, Kazakh, Kannada, Kashmiri, Lao, Malagasy, Malay, Sanskrit, Secwepemctsin, Telugu, Urdu, Xhosa Many thanks to all translators for this final effort. Thanks also to all people who urgently popped up last week to complete the translations for languages that were "orphaned". I hope this will bring us more translators...:-) I keep special thanks to Frans Pop here. He is, along with me, the author of the code that allows us to split D-I translations in "sublevels", allowing translators to focus on the most "important" messages. He also implemented prior warnings when users pick up a language where some less important screens aren't translated. This also allows us to more easily keep partly complete translations, or activate languages earlier. Without this, 11 languages should have been dropped.

Only four days are left and these languages, as well as Amharic, Northern Sami, Slovenian, Albanian, Tagalog are in very high danger of being disabled in Debian Installer. For Bengali, I still have some hope as someone volunteered to fill in the gap left. Catalan is still missing its 5 miserable strings but I guess I won't have the guts to disable it just because it is missing strings that warn users that the translation could be incomplete (feel free to laugh at this paradox but if you think this is stupid, just also feel free to come and fix that bug or complete the damn translation). I can now confess that we will reach a point where we will have less translations for the installer in Lenny than we had in Etch. I don't see any reason for this to change in four days. And, yes, I call this sad news as we (particularly Frans) did a lot of improvement in D-I to lower down the requirements. PS: for those who wonder why I mention only 7 languages in that post's title, I indeed picked up those I still have a small hope I can wake up someone to complete the work in these last four days.

One thing that's annoying about the Debian installer on the NSLU2, as Joey Hess pointed out a few months ago when he reinstalled his NSLU2, is that you have to manually select some installer modules. The reason for this is that the NSLU2 only has 32 MB of RAM and thus Debian installer runs in lowmem mode in which less functionality is enabled by default. As a result of this, you have to select partman-auto, partman-ext3 and usb-storage-modules from a list of additional installer modules to load so the installer will recognize your USB disk, offer guided partitioning and format the disk with ext3. When Joey submitted his installation report, Frans Pop suggested that we could put a list of installer modules we want to have installed automatically in /var/cache/anna/include. I finally got around to playing around with this yesterday and while this specific solution won't work on lowmem systems we can use anna-install to automatically queue installer modules for installation. Since anna-install works, I put some functionality into the installer today to automatically load required installer modules on the Linksys NSLU2 and on Cobalt machines. This change is good for users because they don't have to select some modules during the installation. I'm a little bit worried that existing users of the installer on the NSLU2 will be confused when they don't see the modules in the list anymore, but I'll update the documentation accordingly.

Frans Pop reported recently that the initramfs did not fit in the flash of the QNAP TS-109 when you used LVM. We had problems with initramfs images that were too large before (on the NSLU2). By default, initramfs-tools uses the MODULES=most setting which puts all modules that might be of interest to booting a machine in the initramfs. This is a good idea on a PC where the hardware can change a lot, but it makes less sense on most NAS devices. Frans has now changed debian-installer so the MODULES policy can be chosen during the installation. His change allowed architecture specific defaults, so I've changed ARM to use MODULES=dep. debian-installer will now create the file /etc/initramfs-tools/conf.d/driver-policy with a MODULES setting that will override that from /etc/initramfs-tools/initramfs.conf. On QNAP devices, I intend to only support MODULES=dep installations, so please change your configuration if you've installed Debian already. On the NSLU2, MODULES=most will of course continue to be supported.

Another point release for Etch has been done; now it's the time for the CD team to roll out new images after the next mirror pulse. The official announcements (prepared by Alexander Reichle-Schmehl, thanks!) will follow shortly afterwards. FTP master of the day was Joerg Jaspert, who did his first point release since Woody, as he told us on IRC. We appreciate your work and you spending your time that shortly before going to Argentina. This point release includes the etchnhalf update introducing a new kernel image (based on 2.6.24) and some driver updates. Additionally the infamous openssl hole will be fixed for good, even for new installs. Again I want to present you a list of people who contributed to this release. It cannot be complete as I got the information out of the Changed-by fields of the uploads.

• akira yamada
• Alexander Sack
• Alexander Schmehl
• A Mennucc1
• Andrea De Iacovo
• Andres Salomon
• Aurelien Jarno
• Charles Plessy
• Christian Perrier
• Christian Welzel
• Colin Watson
• dann frazier (indefatigable kernel worker, most sourceful uploads)
• Darren Salt
• Devin Carraway (3rd place of sourceful uploads, due to security work)
• Emmanuel Lacour
• Eric Dorland
• Fabio Tranchitella
• Faidon Liambotis
• Fathi Boudra
• Florian Weimer
• Francesco Paolo Lovergine
• Francois Marier
• Frank Lichtenheld
• Frans Pop (thanks for your d-i work!)
• Frederic Peters
• Gregory Colpart
• Holger Levsen
• Jan Wagner
• Jay Berkenbilt
• J r my Bobbio
• Joey Hess
• Joey Schulze
• Josselin Mouette
• Julien Cristau
• Kai Hendry
• Kurt Roeckx
• LaMont Jones
• Laszlo Boszormenyi
• Martin Pitt
• maximilian attems
• Michael Biebl
• Michael Koch
• Mike Hommey
• Moritz Muehlenhoff
• Noah Meyerhans
• Ola Lundqvist
• Otavio Salvador
• Patrick Matth i
• Petter Reinholdtsen
• Philipp Kern
• Pierre Habouzit
• Raphael Hertzog
• Rene Engelhard
• Robert Millan
• Roberto Lumbreras
• Roland Mas
• Romain Beauxis
• Russ Allbery
• Sean Finney
• Stefan Fritsch
• Steffen Joeris
• Stephen Gran
• Steve Kemp
• Sune Vuorela
• Thijs Kinkhorst (2nd place of sourceful uploads, due to security work)
• Thomas Viehmann
• Toni Mueller
• Tzafrir Cohen

From the Release Team we had dann frazier (who drove the important kernel part of etchnhalf), Luk Claes, Neil McGovern, Andreas Barth, Martin Zobel-Helas and me working on it. ;-)

Last news I gave for D-I and related stuff l10n completion was on June 15th. We're now one month later, so let's see what happened since then. D-I "level 1" (ie the core D-I) had several templates changes which bringed the translation ratio from 100% to 99% and below several times, for all languages. Several teams have still been able to cope with that. Other levels had no changes and I therefore spent some time nagging them to complete the missing bits here and there. The current status is:

• Level 1 (core D-I): 20 complete languages (be cs de eu fi fr gl gu ja ko nl pt pt_BR ro ru sk sv th tr vi) just like we had on June 15th
• Level 1 + Level 2 (packages with strings used in default installs): 20 complete languages as well (the same ones of course). Big improvement here as we had only 11 of them in June.
• Level 1-3 (pkgs prompting during default desktop installs or important for desktop installs): 16 complete languages. We "lose" Belarusian, Gujarati, Brazilian Portuguese, Romanian.
• Level 1-4 (adding pkgs prompting during other tasks): 16 (the same ones)
• Level 1-5 (adding important stuff such as apt, dpkg, aptitude): 9 complete languages. Those languages reaching the Grand Slam are: German, French, Galician, Japanese, Portuguese, Russian, Slovak, Swedish, Vietnamese

Changes are still planned for level 1: D-I developers are really active these days, particularly with the great "come back" of J r my Bobbio and the constant QA work by Frans Pop. I also tried to merge in some work done in Ubuntu's Rosetta and then interest those people who translate there to collaborate to D-I "upstream". This lead me to merge updates for Icelandic, Kazakh, Afrikaans, Malay, Welsh and Serbian. Contacts were made with the relevant translators:

• For Icelandic, the translation updates in Rosetta come from a woman whose login is "eeinarsdottir" but I couldn't succeed in getting an e-mail address to get in touch with her. She apparently lives in Finland if I believe Google and is also using "zorglubb" as nickname. Any hint to get in touch with her would be appreciated.
• For Kazakh, I tried to get in touch with the person who translated in Rosetta but got no answer as of now. In the same time, I tried to re-wake up Talgat, who's registered as the D-I translator but wasn't very successful.
• For Afrikaans, Friedel Wolff, the main maintainer of Pootle, is very interested in working on the translation, through Pootle of course. He was however very reluctant wrt our current policy to activate languages only when people complete "sublevels" 1 and 2....which would require about 6000 words to be updated. Scary for him, as it seems. I tried to get in touch with the translator in Rosetta....but got no answer.
• For Malay, the current translator (NB Liang) was very happy to get more strings translated because of the merge with Rosetta translations. He proposed the Rosetta translator to collaborate: no answer.
• For Welsh, I got a positive contact with Jonathan Price who did some work in Rosetta, completing the old work by Daffyd Harries (Welsh used to be complete in D-I in the past). We'll see if that goes further than "I'll have a look at it".
• By far the most positive contact was for Serbian. In about one week, I managed to get in touch with Veselin Mijuskovic and Marko Uskokovic, who work for the cp6linux project, funded by the Ministry of Telecommunications and Information Society of the Republic of Serbia. This project is aimed at creating a fully localized Linux-based distribution for use in Serbia, with support for Serbian (both cyrillic and latin), as well as regional languages of Serbia. Their distribution is currently based on Ubuntu. They did a lot of l10n work which, unfortunately, did not end up upstream as of now. They gave me access to their Pootle server and I'll try to get some of their work back in Debian.

My conclusion about all this is mitigated: I'm somewhat sorry to see some work happening in Rosetta, still without any connection with "upstream" work, with people apparently working without even some internal coordination and quite anonymously. I wonder if these people know that their work has few chances to end up anywhere, except in Ubuntu (for D-I translation, I even doubt it ends up somewhere: this is just unused work....until I grab it for D-I "suptream").

While I have been a little quiet with ftpmaster posts lately - I am still alive. I just had some other bits to do and didn’t get large enough changes done that would warrant an own post. Since my last post earlier this months there have only been 3 notable changes, namely

• fixing a bug in the transitions feature. Or better - working around one in python-syck which was inserting random “—” when it dumped a data structure. Which does break stuff.
• Changed the Maintainers name of the ftp.debian.org pseudopackage.
• Merged a little branch from Frans that enables automated byhand processing for the tasksel data.
• Started the last discussion on the data section/archive/component thingie and will end that soon with an implementation.

And only a few minutes ago I sent a “Bits from” mail to our debian-devel-announce mailinglist, which includes a summary of the recent activities and changes in our team, with the addition of Thomas and Kalle, me getting FTPMaster and Anthony and James resigning. We also ask for volunteers which we might add to the team later on. See, I write might. We keep the right to reject people, for whatever reason. Hopefully there won’t be many rejects, but still. And we will see how the volunteers get the tasks done we plan to assign to them. You can expect to see a little more in the near future from me again, I don’t plan on staying that quiet forever.

---

And in other news - I recently got another group added, mirroradm, as it did help to fix some mirror issues with packages.debian.org. With that I also got the mirrors@ alias additionally routed into my INBOX. Thats a nicely spammed role address and my tip for you, if you should ever get offered access to (any) role address - run as fast as you can, unless you have very good spam filters! :) Luckily my filters are pretty good, as I’m on a good number of role addresses for a long time already, only a few dozen spams getting through a day (and a thousand filtered away). Comments: 0

Conditional partitioning in debian installer I needed to create an automatic, unattended installer that would repartition the whole disk, but keep an existing home partition if it is already existing. The idea is to replace the operating system, but keep the user's home files. If the home partition does not exist, however, we need to create it. The starting point for this is in Holger's website, which does everything except create the partition if it's missing. The technique I used is to create a udeb that would scan the partitions using /usr/lib/partconf/find-partitions and then load the right preseeding for partman-auto, the automatic partitioner. Here you find the udeb source. I'll comment the most important bits: First, the two partman-auto recipes that we are going to preseed. The format is documented in the debian-installer documentation. This will create /home if missing: And this will keep /home if it exists: Then the postinst file of the package, where the logic is. Otavio and Daniel on #debian-boot have taught me that udebs are, simply put, just big postinsts (installer wise, apart from shipping binaries). Postinst is where the logic is done, or applications are started. Finally, debian/control. The basic bits about creating a d-i udeb are to put it in Section: debian-installer and to use XC-Package-Type: udeb. Then there is XB-Installer-Menu-Item, that defines the order of execution of postinsts. The d-i documentation lists the numbers that are currently assigned. I am using 38 rather than 3800 because I'm targeting etch d-i. After etch, "numbers have been multiplied by 100 from what they were before to give us more space". This is it. debian/rules is just boilerplate, except installing the preseed files in the right place. CDBS is useful to make this self-evident: To build the installer CD with this d-i, I'm using simple-cdd; here are the profile files I'm using at the moment, with the main preseeding for fully unattended install (it is designed to trash your hard disk if you boot it, so only test it in an emulated environment) and the inclusion of the custom udeb.

A while back Frans filed an interesting bug explaining the reason why digits width should always be the same.

Finding out if the previous condition is true, is just a matter of creating a sample text file

FONT="DejaVu Sans Oblique"
OUTFNAME=$(echo $ FONT    sed -e "s   _ g")
numdigits=100
for i in $(seq 0 9) ; do
   for j in $(seq 1 $ numdigits ) ; do
   echo -n $i >> numeri.txt
   done
   printf "\n" >> numeri.txt
done

and creating a waterfall image:

pango-view --font="$ FONT " --waterfall --dpi=72 -q -o $ OUTFNAME .png numeri.txt

The resulting image shows how Dejavu Oblique is victim of a regression at size 9 and 10 (credits to fjp who spotted it once more!)
bugreport filed.

A few clarifications on TDebs in Emdebian:

1. Emdebian needs TDebs now and although discussed in Debian, there is no implementation at this time. Therefore, Emdebian has had to go ahead and implement what we need from TDebs in a manner that should be compatible with Debian TDebs when they eventually arrive.


2. .mo files are architecture dependent and this is a problem for embedded devices, therefore the Emdebian TDeb support must take account of these problems whether or not Debian does so as well.


3. Emdebian will continue to need to cross-build existing Debian packages and if that means regenerating the TDebs to ensure compatibility with embedded devices, that will be done too. It is quite likely as Emdebian will certainly be dropping translated manpages and other content of the proposed Debian TDebs.


4. Emdebian TDebs - as the only implementation currently available - do not support anything except gettext. Again, Debian is likely to provide such support but it is not important to Emdebian because packages that do not use gettext are not in the package set likely to be useful on an embedded device.


5. Tests on non-embedded boxes are irrelevant - yes, .mo files work on any Debian architecture that you care to mention. The problem is that the conversion that is so invisible on a desktop machine becomes a real problem on an iPAQ.


6. I started off thinking that Emdebian TDebs could be Arch:all and the existing packages are Architecture: all but this is set to change. Please don't make the same mistake again and again.

I'm grateful to Frans for his comments during my FOSDEM talk - it will involve extra work to fix the Emdebian TDeb support but it is worthwhile.
Emdebian TDebs are just like Emdebian debs - they are customised versions using Emdebian methods that turn a stock Debian package into something suitable for embedded devices. Debian debs differ from Emdebian debs. Debian TDebs will (when they exist) differ from Emdebian TDebs but the principles of splitting out the .mo files and handling installation etc. are similar.
Packages files
Emdebian needs a different solution to the Debian method, at least initially - principally so that we can have a solution that works now, without extensive changes to the rest of Debian. That solution is available in Emdebian.
Selecting languages
The Debian TDeb proposed method is not implemented currently and GLib includes simple support for retrieving the list of languages selected. Again, Emdebian has implemented a solution that works now, not something that is only a proposal on a wiki page.
Eddy, AFAICT almost nothing has happened to bring TDebs to Debian since Debconf7 and until something concrete exists in Debian, Emdebian simply needs something that works - now.
So:
Q: Are .mo files architecture dependent?
A: Yes.

Q: Does it matter?
A: Yes, for embedded devices.

Q: What about this test or that test?
A: Irrelevant because the tests are done on Debian boxes that convert the data transparently, not an embedded device where the time delay would be problematic.

Q: The packages fill will explode!
A: Yes, it would but both Emdebian and Debian have solutions for this problem.

Q: How to select languages?
A: Normal methods using dpkg and locales, but these are also likely to be customised for embedded usage.

Q: Do tdebs support anything else than gettext?
A: No. Emdebian TDebs only support gettext until such time as Debian has a fully implemented solution that can be customised for embedded devices during the normal Emdebian cross builds.

Updates:

1. the arch issue raised by Frans was not the object of my post. Also, not all points are invalid/reiterated, just the ones iterated here. Thanks Frans.
2. add a note that there is an image that proves that .mo endianness is irelevant - usefull for readers that might miss that

---

While looking at Neil Williams' talk(hi-res/lo-res) from FOSDEM about cross building and tdebs I was STUNNED about the many (not all, thanks Frans) points that were reiterated during that talk when there were already answered.

Well, I guess you have to repeat yourself a lot to get your ideas through to the other side. So, let's do that.

All (except the first) of the following have been already answered one way or another on the TDebs wiki page.

Q: .mo files are arch independent or not? Neil asks again on his blog.
A: It doesn't matter, does it?

0 eddy@bounty ~ $ file /usr/share/locale/ro/LC_MESSAGES/wormux.mo
/usr/share/locale/ro/LC_MESSAGES/wormux.mo: GNU message catalog (big endian), revision 0, 228 messages
0 eddy@bounty ~ $ uname -a
Linux bounty 2.6.24.2-bounty #1 SMP Wed Feb 13 02:34:09 EET 2008 x86_64 GNU/Linux

(there is a picture here which proves my point, if you can't see it, click here).



Q: The packages file will explode
A: No, that's addressed.

Q: How do you select languages?
A: Simply use what we have and expand on that.

Q: Do tdebs support anything else than gettext?
A: Yes.